NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/7681

Internet Message Format | 1996-08-05 | 3.5 KB

Path: EU.net!sun4nl!xs4all!usenet
From: [e-mail] (Jeroen T. Vermeulen)
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.programmer
Subject: Re: toy operating systems, like AmigaOS
Date: Sat, 20 Apr 96 13:45:23
Organization: Leiden University, Mathematics & Computer Science, The Netherlands
Message-ID: <[e-mail]>
References: <[e-mail]> <4kplgo$[e-mail]> <4ksu6q$[e-mail]> <[e-mail]> <4l4cha$[e-mail]>
NNTP-Posting-Host: asd10-02.dial.xs4all.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-NewsSoftware: GRn 2.1 Feb 19, 1994


In article <4l4cha$[e-mail]> [e-mail] (Jonathan Gapen) writes:
>
> > It would be great IMO to have an add-on layer to the OS that aggressively checks
> > and reports everything, but there shouldn't be too much reason for the user to
> > run that.
>
>    May I point out again that until programming methods improve drastically,
> *all* non-trivial software will have bugs.  The user still needs some
> protection, because sooner or later, something will break.

True!  But I don't wholly agree with the notion that protection is, and should
be, an absolute matter either.  It's still a tradeoff between factors such as
risk, shooting yourself in the foot (complicated protection systems can have
bugs of their own, or encourage bugs in other software), and costs *.

In my experience the worst problem with bugs is not so much when they don't
occur until the customer bumps into them, but when they do occur yet produce no
noticable effect during testing.  Hence my preference for a split system
(developer one which notifies of every slight error, and a lightly protected one
for the user) over a UNIX-style OS that quietly swallows everything so that
glaring bugs can stay hidden for years.

As an example, with Purify I once found a bug in one of my own programs (true!):
During the final iterations of a loop, it read the -1st entry of a malloc()'d
array.  No amount of memory protection would ever catch this because it was
within malloc()'s administration struct.  If the number found there fell between
1 and some small positive value (extremely unlikely), some incorrect data would
be generated and the loop would continue on the -2nd entry.  If the number found
there were between 1 and the one at the -1st entry (even more unlikely), a core
dump would probably occur.

Bugs like this one, and you can't convince me they are a rare variety, can lead
a latent existence for years, waiting for the Murphiest moment to make their
appearance.  They can't be reasonably caught by protection, but they can by
debugging tools during rigorous testing.


--footnotes--
* I believe the correctness problem is undecidable in the general case, thus a
  protective system has three basic options:  (1) Risking infite computation
  time for deciding what is "safe", (2) flagging potentially harmless actions as
  "unsafe", or (3) incomplete protection.
--footnotes--


> Jonathan Gapen ([e-mail])
> Bread in, toast out. How does it DO that?

--
============================================================================
#  Jeroen T. Vermeulen   \"How are we doing kid?"/   Yes, we use Amigas.   #
#---  [e-mail]    ---\"Oh, same as always."/--         ...          --#
#[e-mail] \ "That bad, huh?"  /  Got a problem with that? #
A Pentium is like a miracle:  They do exist but I wouldn't count on them.